home *** CD-ROM | disk | FTP | other *** search
-
-
- IEN 170
- Danny Cohen
- Jon Postel
- USC / ISI
- January 25th, 1980
-
-
- ON IP-ADDRESSING
- ----------------
-
- At some early point we agreed that an IP address is always a 32-bit
- address, composed of 8-bit NET-ID, followed by a 24-bit "REST" field.
-
- This implied that:
-
- 1. All the networks in our universe must have an 8-bit identifier;
- and
- 2. All intra-net addresses must fit into a 24-bit field, somehow.
-
- It also implies that:
-
- 3. Our gateways must know about all of our (up to) 256 networks.
-
-
- Since it became clear that these assumptions may not reflect the real
- world, which is outside of our IN group, we patched the situation by
- defining Source Routing (SR) which was expected to be equivalent to the
- Extensible-Addressing which should have been used initially.
-
- However, the way our source route option is handled does not really
- solve the situation. It appears as if the implementation of this
- capability is optional, even though the documentation clearly states
- that the implementation of the options is mandatory, only their use of
- any given datagram is optional, as stated on p.29 of IEN-128.
-
- We do not know how many gateways actually have implemented the source
- routing options, if any. We doubt if any TCP implementation is actually
- capable of communicating Source Routing to the IP level below it,
- request a Return-Route and know how to handle it once it arrives at the
- IP.
-
- However, our definition of Source-Route as a sequence of IP-addresses
- does not expand our addressing capabilities at all. Only IP-addresses
- (which can be specified directly) may be specified by the Source-Route.
- Both the direct addressing and the Source-Route are designed to specify
- destinations which are under our control, in networks which agree to be
- part of our addressing plan.
- 2
-
- This a serious deficiency. Hosts on public nets, for example, require 14
- digits of address which is beyond our 24-bits capability, likewise PUP
- addresses require more than 24 bits.
-
- In order to overcome this deficiency IEN-122 has suggested that
- ESCAPE-CODEs be defined in the space of NET-ID's.
-
- The idea of Escape-Codes met no objections, and was added to the (long)
- list of wouldn't-it-be-nice's which were never implemented.
-
- The introduction of the Escape-Codes into the NET-ID space requires no
- change to the definitions of either IP or TCP which are already casted
- in concrete. Therefore, LET'S DO IT, NOW !!!
-
- The numbers-Czar would be willing, rumors say, to assign such Escape-
- Code(s).
-
- This still leaves us with the reality of lack of Source-Routing, even
- though it is on the books.
-
- Three approaches may be taken:
-
- (A) Enforce implementation of Source Route as described
- in the official documents, IEN-128.
-
- (B) Recognize the mistake, apologize and re-do it right:
- introduce Extensible- Addresses.
-
- (C) Do nothing.
-
- Obviously (B) is the toughest to implement, and (C) is the easiest.
-
-
-
- We recommend that:
-
- 1. The implementation of Source-Routing (SR) be "enforced".
- This includes both IP code in gateways and hosts, and its
- interface to the higher level protocol (e.g., TCP).
-
- 2. ESCAPE-CODEs be defined in the space of NET-ID's, to allow
- addressing extensions beyond the IP-world (e.g., dialup
- lines, PUP and public networks).
-